<html>

<head>
  <META NAME="copyright" CONTENT="Copyright 2001 by MandrakeSoft S.A.">
  <META NAME="Author" CONTENT="Kevin Lawton">
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
  <TITLE>Coding Guidelines For Bochs</TITLE>
</head>

<body TEXT="#000000" BGCOLOR="#ececec"  LINK="#3333cc" VLINK="#666666">

<center><h1>Coding Guidelines For Bochs</h1></center>

<br>
<ul>
<li> <u>Don't make use of any external C++ classes.</u> &nbsp;They are not offered
  on all platforms and this would make bochs non-portable. &nbsp;There is use of
  such classes in the optional debugger. &nbsp;I plan on removing this use.

<li> <u>Don't use fancy C++ features.</u> &nbsp;Bochs is incredibly
     performance sensitive, and will be increasingly so as more speed
     enhancements are added. &nbsp;There's a time and place for most
     everything and this is not it. &nbsp;Some advanced features
     create overhead in the generated code that you don't see.
     They also convolute the code, and sometimes occlude
     what is really going on.
  <ul>
  <li> Don't use templates.
  <li> Don't use virtual functions.
  <li> Don't use C++ exceptions.
  <li> Don't use overloading of any kind.
  </ul>
<li> <u>Use soft tabs.</u>  At least when you submit code, convert all
     hard tabs to spaces.  There is no uniform way to handle
     tabs properly.
<li> <u>Prefix screen spew with a pound sign ('#').</u>
     If you want to spew something out to the screen rather than
     the bochs.out file, send it to stderr (not stdout), and prefix the string
     with a pound sign.  This is so that a text interface which
     drives bochs (the debugger) can discern between messages and
     command responses.
<li> <u>Please do compile with all warnings turned on.</u> &nbsp;It's really
     difficult to spot interesting warnings when a compile is littered
     with non-interesting ones.
<li> <u>Don't use signed ints where unsigned will do.</u>
</ul>

</body>
</html>
